Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix 0-length range responses. #87

Merged
merged 2 commits into from
Aug 1, 2013

Conversation

pmundkur
Copy link
Contributor

@pmundkur pmundkur commented Nov 6, 2012

There were two issues:

  • file:pread() returns eof in the case when the length of the
    read is 0 bytes, for any offset. This causes badarg exceptions
    later in iolist_size when the 'eof' atom is encountered instead
    of a binary

  • The range-length computation is off by 1 for 0-length ranges:
    {Skip, Skip + Length - 1, PartialBody} would result in e.g.
    {0, -1, eof}. {0, -1} is invalid HTTP according to

    http://tools.ietf.org/html/rfc2616#section-14.16

    A byte-content-range-spec with a byte-range-resp-spec whose
    last-byte-pos value is less than its first-byte-pos value,
    or whose instance-length value is less than or equal to its
    last-byte-pos value, is invalid.

This patch fixes both issues.

There were two issues:

- file:pread() returns eof in the case when the length of the
  read is 0 bytes, for any offset.  This causes badarg exceptions
  later in iolist_size when the 'eof' atom is encountered instead
  of a binary

- The range-length computation is off by 1 for 0-length ranges:
  {Skip, Skip + Length - 1, PartialBody} would result in e.g.
  {0, -1, eof}. {0, -1} is invalid HTTP according to

  http://tools.ietf.org/html/rfc2616#section-14.16

     A byte-content-range-spec with a byte-range-resp-spec whose
     last-byte-pos value is less than its first-byte-pos value,
     or whose instance-length value is less than or equal to its
     last-byte-pos value, is invalid.

This patch fixes both issues.
@etrepum
Copy link
Member

etrepum commented Nov 6, 2012

It'd be really great if there were tests that showed the issue and ensured that this doesn't regress

@pmundkur
Copy link
Contributor Author

pmundkur commented Nov 6, 2012

I didn't find any existing tests in mochiweb_{http, request} that could be adapted for the purpose. Where should I look?

@etrepum
Copy link
Member

etrepum commented Nov 16, 2012

Well, it doesn't appear that there's an obvious test in this repo that you can just copy and modify. The way that I've done this kind of test in the past is to just have the test start up a server listening on a random port on loopback, send a request to that port with the right headers, and inspect the response for correctness. A bit heavyweight but it does verify the functionality and cover all of the code in that path.

@pmundkur
Copy link
Contributor Author

The problem with such tests is that they tend to be sensitive to timing (see for e.g. the tests I supplied for pull #44). You suggested there to use meck instead; that is probably a better approach, but I won't be able to get to it anytime soon.

@etrepum
Copy link
Member

etrepum commented Nov 22, 2012

I don't see why this kind of test would be sensitive to timing. Start a
server, connect to said server and send a request, read the full response
and verify the assumptions.

On Wed, Nov 21, 2012 at 11:14 PM, Prashanth Mundkur <
notifications@github.com> wrote:

The problem with such tests is that they tend to be sensitive to timing
(see for e.g. the tests I supplied for pull #44#44).
You suggested there to use meck instead; that is probably a better
approach, but I won't be able to get to it anytime soon.


Reply to this email directly or view it on GitHubhttps://github.com//pull/87#issuecomment-10625543.

etrepum added a commit that referenced this pull request Aug 1, 2013
@etrepum etrepum merged commit 510766b into mochi:master Aug 1, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants